Modern wireless communication networks are ubiquitous in many parts of the world. With advances in technology, and sophisticated protocols and standards (e.g., 3GPP technical standards), wireless networks deliver far more services than the paging and mobile telephony for which they were originally designed. One such advanced service is the ability of a network to transmit the same information to all User Equipment (UE) within one or more cells (broadcast), or to a select group of UE (multicast). To facilitate this service, the Broadcast/Multicast Control (BMC) protocol is defined as part of the Group Radio Access Network (GRAN) in 3GPP Technical Specification 25.324, “Broadcast/Multicast Control BMC,” the disclosure of which is incorporated herein by reference in its entirety.
3GPP TS 25.324 defines BMC as a sublayer in the user plane of Layer 2 of the network layer protocol stack. To place the BMC in context, FIG. 1 depicts a diagram of the relevant parts of the UTRA FDD radio interface protocol architecture 10. The BMC 12 resides in Layer 2 above the Radio Link Control (RLC) layer 14, which maps logical channels. The RLC 14 itself resides above the Media Access Control (MAC) layer 16, which maps traffic channels. Layer 1 includes the Physical (PHY) layer 18, which implements transmission and reception. Layer 3 includes the Radio Resource Control (RRC) layer 20, which provides control for the BMC 14, RLC 16, MAC 18, and PHY 20. The BMC 12 is transparent for all services other than broadcast/multicast. Note that the BMC exists only in the user plane.
On the network side, the BMC implements the Cell Broadcast Service (CBS). CBS is described herein in the context of UTMS; however it is also implemented in other air interface protocols, such as GSM. Accordingly, the description herein is illustrative only and is not limiting. Cell broadcast messages are Short Message System (SMS) text messages, although they are not encumbered by the length restriction of SMS text messages. A CBS message consists of one or more CBS pages, each comprising 82 octets. A CBS message may include up to 15 CBS pages. CBS messages are normally repeated, to increase the probability of successful reception by many UE.
All UE capable of receiving CBS messages (that are in idle, CELL_PCH, or URA_PCH RRC-states of Connected mode) may receive each CBS message. The CBS message includes a message ID that identifies the source and type of the CBS message. By inspection of the type in the message ID, individual UEs receiving a CBS message may forward the message to higher layers or discard it, depending on whether the UE is subscribed to a CBS service for that type. In this manner the BMC implements multicast, wherein only groups of subscribers receive certain message types (e.g., news, sports, weather, stock prices, and the like).
Each CBS message is delivered in a Physical Data Unit (PDU), and includes various Information Elements (IE). Each CBS message includes a Message Type IE (distinct from the type of CBS service described above). There are three types of CBS message PDUs: CBS message, CBS41 message, and schedule message. A BMS CBS message carries cell broadcast/multicast data and address information for GSM based CBS. A CBS41 message carries cell broadcast/multicast data and address information for ANSI-41. A scheduling message defines the schedule of CBS messages, including the next schedule message, in a succeeding CBS schedule period, which is defined in terms of a number of Common Traffic Channel (CTCH) block sets. Scheduling messages allow for support for UE discontinuous reception (DRX) to preserve battery life.
The CBS schedule message defines a succeeding CBS schedule period by defining an Offset to Begin CTCH BS index IE (defining the beginning of the next period) and a Length of CBS Scheduling Period IE (defining the duration of the next period). The CBS schedule message also includes a New Message Bitmap IE that identifies every CTCH BS in the next period during which a complete or partial CBS PDU will be transmitted. The CBS schedule message further includes a Message Description IE for each CBS PDU identified in the New Message Bitmap. The Message Description IE include a Message ID and Message Description Type for each CBS PDU. The encoding of the Message Description Type (MDT) field is presented in FIG. 2 (Table 11.9-3 of 3GPP TS 25.324). Note that MDT 1 and 0 identify new (and repetitions of new) CBS messages, and MDT 5 and 4 identify old (and repetitions of old) CBS messages. MDT 6 identifies the CBS schedule message of the next period.
In the next period, the UE must receive all new CBS messages; it may ignore old CBS messages that it has already received. However, prior to receiving each old CBS message, the UE knows the Message ID, but does not know the Message Serial Number, which is an IE transmitted only in CBS message PDUs (not the CBS scheduling message PDU). Thus, for old messages, the UE cannot determine whether it has previously received the message or not. Accordingly, the UE must receive the message. Upon reception, the UE may inspect the Message Serial Number IE to determine whether it has previously received the CBS message. If not, it passes the CBS message to higher layers; if the UE has previously received the CBS message, the UE may discard it. The reception, downconversion, demodulation, decoding, and other processing required to receive an old CBS message, which the UE later learns it had previously received and thus discards, severely and unnecessarily drains UE battery power.
To address this deficiency, in 3GPP Release 6, a Change Request was introduced to 3GPP TS 25.324: CR 0028, “Introduction of Serial Number in BMC Schedule Message.” While this should provide Serial Number information to the UE regarding all old CBS messages in the upcoming period, discussions with network operators and inspection of extant networks reveals that the CR has not been widely implemented. Accordingly, the Rel. 6 CR is ineffective to resolve the above-described problem in real-world, deployed networks.
Accordingly, a need exists in the art for a method of reliable BMC message handling in the UE, which does not unnecessarily deplete UE battery life, in the absence of network side support for Serial Number identification.
The Background section of this document is provided to place embodiments of the present invention in technological and operational context, to assist those of skill in the art in understanding their scope and utility. Unless explicitly identified as such, no statement herein is admitted to be prior art merely by its inclusion in the Background section.